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Description 

BACKGROUND OF THE INVENTION 

5 1 . Field of the Invention 

[0001] The present invention relates generally to a method for allocating a common channel in a CDMA (Code Di- 
vision Multiple Access) mobile communication system, and in particular, to an apparatus and method for allocating a 
common channel in the case that a serving radio network controller (SRNC) is different from a drift radio network 
10 controller (DRNC). 

2. Description of the Related Art 

[0002] With the rapid development of the mobile communication industry, a future mobile communication system will 
15 provide not only a voice (circuit) service but also advanced services such as a data service and an image service. 
Generally, the future mobile communication system employs a CDMA (Code Division Multiple Access) system. The 
CDMA system is classified into a synchronous system and an asynchronous system. The synchronous system is chiefly 
adopted in United States, while the asynchronous system is mainly adopted in Europe and Japan. However, the stand- 
ardization work on the future mobile communication system is being separately carried out forthe synchronous system 
20 and the asynchronous system. The European future mobile communication system is called "UMTS (Universal Mobile 
Telecommunication System)". 

[0003] The standardization provides various specifications for the data service and the images service as well as 
the voice service, required in the future mobile communication system, and particularly, for channel allocation. 
[0004] A UMTS W-CDMA (Wideband Code Division Multiple Access) communication system, the European future 

25 mobile communication system, uses a random access channel (RACH) and a common packet channel (CPCH) as a 
reverse common channel, and uses a forward access channel (FACH) as a forward common channel. 
[0005] Among the reverse common channels of the W-CDMA communication system, the RACH can have charac- 
teristics dependent on a TTI (Transmit Time Interval) and a channel coding mode, and is mapped with a physical 
random access channel (PFtACH) on a one-to-one basis. Further, the PRACH can have characteristics being depend- 

30 ent on available signatures and an access sub-channel. Therefore, the RACHs can be distinguished (identified) based 
on the TTI and the channel coding mode, while the P RACHs can be distinguished according to the number of available 
signatures and the access sub-channel. In addition, an available spreading factor (SF) can be also used in distinguish- 
ing the PRACHs. 

[0006] As the RACHs and PRACHs have various characteristics, they can be used for different purposes according 
35 to their service types. In addition, information on the RACH/PRACH is broadcast by a Node B, and upon receiving the 
RACH/PRACH information, a UE can select which RACH/PRACH to use depending on the received RACH/PRACH 
information. Alternatively, the Node B can select the RACH/PRACH to be used by a specific UE based on a service to 
be used by the UE, and then inform the UE of the selected RACH/PRACH. 

[0007] Like the RACH, the FACH and the CPCH also have different characteristics to provide different services, so 
40 that the UE can select proper FACH and CPCH according to the characteristics of the FACH and CPCH provided from 
the Node B. Alternatively, the Node B can determine the FACH and the CPCH to be used by the UE and then transmit 
information on the determined FACH and CPCH to the UE. 

[0008] Meanwhile, common channels such as the RACH, the FACH and the CPCH are allocated to the UEs by a 
serving radio network controller (SRNC). The SRNC connected to a core network (CN) exchanges information on a 
45 service provided between the UE and the CN. The SRNC determines a channel to be allocated to the UE using the 
service information transmitted from the CN. 

[0009] Shown in Tables 1 A to 1 C are RAB (Radio Access Bearer) parameters of a service information message used 
by the CN to inform the SRNC of the service information. 



so Table 1 A 





IE/Group Name 


Presence 


Range 


IE type and reference 


Semantics description 




RAB parameters 










55 


>Traffic Class 


M 




ENUMERATED 
(conversational, streaming, 
interactive, background, ...) 


Desc: This IE indicates the 
type of application for which 
the Radio Access Bearer 
service is optimised 
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Table 1A (continued) 





IE/Group Name 


Presence 


Range 


IE type and reference 


Semantics description 




RAB parameters 










5 
10 


>RAB Asymmetry Indicator 


M 




ENUMERATED 
(Symmetric bidirectional 
Asymmetric Uni directional 
downlink, Asymmetric Uni 
directional Uplink, 
Asymmetric 
Bidirectional, ...) 


Desc: This IE indicates 
asymmetry or symmetry of 
the RAB and traffic direction 



15 



20 



25 



30 



35 



40 



Table 1B 



>Delivery Order 



M 



ENUMERATED 
(delivery order 
requested, delivery 
order not requested) 



Desc: This IE 
indicates that 
whether the RAB 
shall provide In- 
sequence SDU 
delivery or not 
Usage: 

Delivery order 
requested: in 
sequence delivery 
shall be guaranteed 
by UTRAN on all 
RAB SDUs 

Delivery order net 
requested: in 
sequence delivery is 
not required from 
UTRAN 



>Maximum SDU 
size 



M 



INTEGER (0.32768) 



Desc: This IE 
indicates the 
maximum allowed 
SDU size 



The unit is: bit. 



Usage: 

Conditional value: 
set to largest RAB 
Subflow 
Combination 
compound SDU size 
when present 
among the different 
RAB Subflow 
Combination 
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Table 1 B (continued) 



5 
10 


>SDU parameters 




1 to 

<max R ABSubf lows 


See below 


Desc: This IE 
contains the 
naramptpr^ 

L-/ CI 1 CU 1 IClw 1 O 

characterizing the 
RAB SDUs 
Usage 

f^K/pn nor ciiKflnw 

uuith firct fwnron^o 
WW! lllol UUUUIcllUc 

\ co[jui lull ty isj 

suDTiowffi eic 




>Transfer Delay 


C-iftrafficCo nv- 




INTEGER (0.. 


Desc: This IE 






Stream 




65535) 


indicates the 


15 










maximum delay for 












95th percentile of 












the distribution of 












delay for all 












delivered SDUs 


20 










during the lifetime of 












a RAB, where delay 












for an SDU Is 












defined as the time 












from a request to 


25 










transfer an SDU at 












one SAP to its 












delivery at the other 












SAP 


30 










The unit is: 












millisecond. 












Usage: 


35 













Table 1C 



40 
45 
50 


>Traflic Handling priority 


C - iftrafficlntera ctiv 




INTEGER (spare (0), 
highest (1), lowest (14), 
no priority used (15)} 
(075) 


Desc.: This IE specifies 
the relative importance 
for handling of ail SDUs 
belonging to the radio 
access bearer compared 
to the SDUs of other 
bearers 

Usage: 




> A (location/Retention 


O 




See below 


Desc: This IE specifies 




priority 








the relative importance 












compared to other Radio 


55 










access bearers for 












allocation and retention of 












the Radio access bearer. 
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Table 1C (continued) 



5 
10 










Usage! 

it in is it is noi receivea, 
the request is regarded 
as it cannot trigger the 
preemption process and 
it is vulnerable to the 
DreemDtion oroeess 




>Source Statistics 


C-iftrafficCo nv-Stream 




ENUMERATED (speech, 


Desc: This IE_specifies 




descriptor 






unknown, ? 


characteristics of the 












source of submitted 


15 










SDUs 












Usage: 


20 













[0010] The SRNC selects a dedicated channel (DCH) or a common channel using the RAB parameters shown in 
Tables 1 A to 1C. If the common channel is selected, the SRNC can select the RACH or the CPCH in response to a 
service request. In addition, a maximum bit rate and a guaranteed bit rate are used in selecting a minimum SF and a 
25 channelization code to be used by the common channel. That is, the SF and the channelization code to be used by 
the common channel are determined depending on the maximum bit rate and the guaranteed bit rate. Here, the max- 
imum bit rate and the guaranteed bit rate are bit rate information of the packet data. 

[0011] In addition, a traffic handling priority and a transfer delay are selected based on the characteristics of the 
physical channel, i.e., based on the sub-channel and the number of signatures. 

30 [0012] When the UE, with a channel allocated by the SRNC, performs a handover (or handoff), a DRNC. an RNC 
of a Node B newly accessed by the UE, and the SRNC may be changed. The SRNC and the DRNC are distinguished 
from the viewpoint of the UE. If the SRNC is connected to the UE not directly, but through the DRNC, then the SRNC 
cannot personally select a channel and allocate the selected channel to the UE. 
[0013] The reasons that the SRNC cannot personally allocate a channel to the UE are as follows. 

35 [0014] First, channels allocated to a cell in the DRNC are determined by the DRNC, because the SRNC does not 
have information on the allocated common channel in the DRNC. For this reason, the SRNC cannot determine a 
common channel allocated to the cell in the DRNC. Second, the DRNC or the CN does not have information on a 
service provided to the UE, so it is difficult to allocate a common channel to be used by the UE. Thus, conventionally, 
when the SRNC is connected to the UE through the DRNC, i.e., when the UE performs a handover, the UE cannot be 

40 allocated a common channel. 

ETSI TS 125 423 V3.3.0 is the technical specification describing the UTRAN lur Interface RNSAP Signalling in UMTS. 
The common transport channel resources initialization procedure is used by the SRNC for the initialization of the 
common transport channel user plane towards the DRNC and/or for the initialization of the UE context in the DRNC. 
Successful operation of the common transport channel resources initialization procedure includes a COMMON TRANS- 

45 PORT CHANNEL RESOURCES REQUEST from the SRNC to the DRNC, and a COMMON TRANSPORT CHANNEL 
RESOURCES RESPONSE from the DRNC to the SRNC. The COMMON TRANSPORT CHANNEL RESOURCES 
REQUEST comprises the following lEs: message type, transaction ID, D-RNTI, C-ID, transport bearer request indicator, 
and transport bearer ID. D-RNTI is the UE context identifier in the DRNC. The transport bearer ID uniquely identifies 
an lur transport bearer. The transport bearer request indicator indicates whether an lur transport bearer needs to be 

so established for carrying the FACH data stream(s), or whether an existing transport bearer will be used. The FDD 
message of the COMMON TRANSPORT CHANNEL RESOURCES RESPONSE comprises, inter-alia, FACH and 
RACH info lEs. 

WO 00/441 91 A1 discloses a method and apparatus for speeding up the connection setup during handover in advanced 
cellular networks. A new connection is requested from a destination access network to a remote peer and by a mobile 
55 terminal, whereupon a connection setup is initiated by the destination access network by sending a handover request 
to a serving access network, bundling connection parameters associated with an old connection by the serving access 
network, transferring the bundled connection parameters to the destination access network, and establishing a new 
connection to the remote peer connection by the destination access network using the transferred connection param- 
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eters. The bundled connection parameters may comprise a peak packet rate. AAL2 connection specific information 
such as data rate is transferred from the S-RNC to the D-RNC at the start of the handover process. The serving and 
destination access networks may be radio network controllers. 

5 SUMMARY OF THE INVENTION 

[0015] It is, therefore, the object of the present invention to provide a method and system in which a serving radio 
network controller (SRNC) shares service information provided from a core network, so that a drift radio network con* 
trailer (DRNC) can allocate a common channel to a UE. 
10 [0016] This object is solved by the invention as claimed in the independent claims. 
[0017] Preferred embodiments are defined by the dependent claims. 

[0018] It is an aspect of the present invention to provide a method in which an SRNC provides a signaling message 
having service information received from a CN to a DRNC, so that the SRNC and the DRNC exchange information 
required in allocating a common channel to a specific UE handed over from the SRNC to the DRNC. 

15 [0019] There is provided a method for setting a common channel for a packet data service by an SRNC through a 
Node B to a UE and a DRNC when the UE is handed over from a first Node B to a second Node B as the UE moves 
to the second Node B, in a mobile communication system. The mobile communication system includes the UE, the 
first Node B providing the packet data service to the UE, the SRNC connected to the first Node B, and a CN (Core 
Network) connected to the SRNC. The CN has bit rate information for the packet data service and transmits the bit 

20 rate information to the SRNC. The SRNC stores the bit rate information. The DRNC is connected to the second Node 
B neighboring the first Node B and also connected to the SRNC. The SRNC transmits service parameters including 
the bit rate information for the packet data service to the DRNC, and receives information on a common channel 
determined based on the service parameters from the DRNC. The SRNC transmits information on the determined 
common channel to the UE through the DRNC and the second Node B, to allocate the determined common channel 

25 to the UE. 

[0020] Preferably, the bit rate information includes a maximum bit rate and a guaranteed bit rate. 

[0021] Preferably, the common channel includes a common packet channel (CPCH), a random access channel 

(RACH) or a forward access channel (FACH). 

30 BRIEF DESCRIPTION OF THE DRAWINGS 

[0022] The above and other objects, features and advantages of the present invention will become more apparent 
from the following detailed description when taken in conjunction with the accompanying drawings in which: 

35 FIG. 1 illustrates a method for allocating a common channel to a UE in the case where an SRNC is different from 

a DRNC, according to an embodiment of the present invention; 

FIG. 2 illustrates a procedure for transmitting service parameters required for allocating a common channel from 
the SRNC to the DRNC according to an embodiment of the present invention; 

FIG. 3 illustrates a procedure for transmitting information required for allocating a common channel from the DRNC 
40 to the SRNC according to an embodiment of the present invention; 

FIG. 4 illustrates a procedure for transmitting the service parameters required for allocating a common channel 
from the SRNC to the DRNC according to another embodiment of the present invention; and 
FIG. 5 illustrates a procedure for transmitting information required for allocating a common channel from the DRNC 
to the SRNC according to another embodiment of the present invention. 

45 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

[0023] A preferred embodiment of the present invention will be described herein below with reference to the accom- 
panying drawings. In the following description, well-known functions or constructions are not described in detail since 
so they would obscure the invention in unnecessary detail. 

[0024] The present invention provides two different embodiments for allocating a common channel to a UE in the 
case where an SRNC to which the UE belongs is different from a DRNC. 

[0025] In a first embodiment, the SRNC transmits service information received from a CN to the DRNC. Upon re- 
ceiving the service information, the DRNC selects a common channel based on the received service information and 
55 then allocates the selected common channel to the UE. 

[0026] In a second embodiment, the SRNC selects a common channel service information received from the CN 
and transmits information on the selected common channel to the DRNC. Upon receiving the information on the com- 
mon channel, the DRNC allocates a common channel to the UE based on the received common channel information. 
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In the first and second embodiments, the common channel selected by the SRNC may be identical to or different from 
the common channel selected by the DRNC. 

[0027] A description of the first embodiment will be given herein below. As stated above, the service information 
transmitted from the CN to the SRNC is shown Tables 1 A to 1C. In this embodiment, the SRNC should transmit the 
s service information received from the CN to the DRNC. Thus, a definition of a message transmitted from the SRNC to 
the DRNC will be given. 

[0028] The SRNC can transmit the service information received from the CN to the DRNC by including it in a Common 
Transport Channel Resources Request message. The SRNC transmits some or all of the service information received 
from the CN to the DRNC, using the Common Transport Channel Resources Request message. Upon receiving the 
10 Common Transport Channel Resources Request message, the DRNC detects the service information included in the 
received Common Transport Channel Resources Request message. The DRNC then allocates a common transport 
channel or a common physical channel to the UE based on the detected service information. Shown in Table 2 is a 
format of the Common Transport Channel Resources Request message according to the first embodiment of the 
present invention. 

15 

Table 2 



20 


IE/Group Name 


Presence 


Range 


IE type and 

reference 

reference 


Semantics 
description 


Critical ity 


Assigned 
Criticality 


Message Type 


M 




9.2.1.40 




YES 


Reject 




Transaction ID 


M 




9.2.1.59 




YES 


Reject 




D-RNTI 


M 




9.2.125 




YES 


Reject 


25 


C-ID 


o 












30 


Tran^DortRparer 

1 1 Cll IOL/VI I l^wul Wl 

Request 
Indicator 


M 




9.2.1.61 


Request a new 
transport bearer 
or to use an 
existing bearer 
for ine user 
plane 


YES 


Reject 


35 


Transport Bearer 

ID 


M 




9.2.1.60 


Indicates the lur 
iranspon Dearer 
to be used for the 
user plane 


YES 


Reject 




RAB information 




0..1 












>Traffic Class 


0 












40 


>RAB 

Asymmetry 

Indicator 


O 












45 


>Maximum Bit 
Rate 


o 














>Guaranteed Bit 
Rate 


o 














>Delivery Order 


o 












50 


>Transfer Delay 


o 














>Traffic Handling 
priority 


o 












55 


>Allocation/ 
Retentio n 
priority 


o 














>Priority level 


o 
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Table 2 (continued) 



5 


IE/Group Name 


Presence 


Range 


IE type and 

reference 

reference 


Semantics 
description 


Critical ity 


Assigned 
Criticality 




>Pre-emption 
Capability 


O 












10 


>Pre-emption 
Vulnerability 


O 














>Queuing 
allowed 


O 













15 



20 



[0029] Table 2 shows some of the service information received from the CN. Specially, it is noted that in table 2, 
parameters mentioned following "the RAB information" row, i.e., from m >Trafftc Class" to ">Queuing Allowed", can be 
included in the RAB information and thus, they can be grouped in the RAB information. That is, in selecting service 
information required for selecting a common channel, the SRNC may select all of the service information received from 
the CN or partially selects only the necessary information shown in Table 2. 

[0030] The service information required by the DRNC in allocating a common channel to the U E includes the following 
parameters that should be transmitted from the SRNC to the DRNC. 



25 



30 



(1) Maximum Bit Rate 

[0031] The maximum bit rate represents a requirement for a maximum value of a bit rate of data to be transmitted/ 
received over the common channel. Therefore, upon receiving the maximum bit rate, the DRNC allocates the common 
channel within a range not exceeding the maximum bit rate. This is because the maximum bit rate can become a 
criterion for determining a spreading factor (SF) indicating a bit rate for a physical channel. Therefore, the maximum 
bit rate can become a criterion for selecting a random access channel (RACH) rather than a common packet channel 
(CPCH),fortheSF<32. 

(2) Guaranteed Bit Rate 



35 



40 



45 



50 



55 



[0032] The guaranteed bit rate represents a req uirement for a guaranteed value of a bit rate of data to be transmitted/ 
received overthe common channel. Therefore, upon receiving the guaranteed bit rate, the DRNC allocates the common 
channel within a range capable of guaranteeing the received guaranteed bit rate. For example, if the received guar- 
anteed bit rate requires a spreading factor SF=1 6, the DRNC allocates the CPCH rather than the RACH. In addition, 
the DRNC allocates a CPCH set capable of supporting the SF=1 6 among CPCH sets. Likewise, even in the case of a 
forward access channel (FACH), the DRNC allocates a secondary common control physical channel (S-CCPCH) ca- 
pable of supporting the spreading factor SF=16. 

[0033] In addition to the maximum bit rate and the guaranteed bit rate, the service information required by the DRNC 
in allocating a common channel to the UE includes Traffic Class, RAB Asymmetry Indicator, Delivery Order Transfer 
Delay, Traffic Handling Priority, and Allocation/Retention Priority parameters. These parameters can be used by the 
DRNC as criterions for selecting a common channel. 

[0034] FIG. t illustrates a method for allocating a common channel to a UE in the case where an SRNC is different 
from a DRNC, according to an embodiment of the present invention. Referring to FIG. 1, upon receiving an RAB 
parameter message with service information from a CN 30 (Step 100), an SRNC 20 determines service parameters 
to be transmitted to a DRNC 1 0 among the service information (or service parameters) included in the received RAB 
parameter message (Step 101). As mentioned above, however, the SRNC 20 can also select a specific common 
channel among available common channels and transmit the selected common channel. For example, in the case of 
an uplink, the SRNC 20 can previously determine (select) a common channel to be used between the RACH and the 
CPCH, and then transmit information of the determined common channel. In this case, the SRNC 20 must recognize 
whether the DRNC 10 provides the CPCH. 

[0035] After determining the service parameters to be transmitted to the DRNC 10 among the service parameters 
received from the CN 30, the SRNC 20 transmits the determined service parameters or information on the type of the 
selected common channel to the DRNC 10 along with a Common Transport Channel Resources Request message 
(Step 102). Of course, it is also possible to define a new procedure instead of using the Common Transport Channel 
Resources Request message. 
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[0036] Upon receiving the Common Transport Channel Resources Request message from the SRNC 20, the DRNC 
10 determines a common channel to be used by the UE by detecting the service parameters included in the received 
Common Transport Channel Resources Request message and analyzing the detected service parameters (Step 1 03). 
The DRNC 10 can also determine the common channel to be allocated to the UE considering a current state of the 
5 common channels in addition to the service parameters included in the received Common Transport Channel Resourc- 
es Request message. That is, the DRNC 10 can select a common channel less frequently used by other UEs among 
a plurality of available common channels. 

[0037] After determining the common channel to be allocated to the UE, the DRNC 1 0 transmits information on the 
determined common channel to the SRNC 20 along with a Common Transport Channel Resources Response message 

10 (Step 1 04). The Common Transport Channel Resources Response message may include additional information such 
as information on a transport channel and a physical channel of the determined common channel, or its priority. 
[0038] A procedure for transmitting the service parameters from the SRNC 20 to the DRNC 1 0 and a procedure for 
determining a common channel by the DRNC 10 using the service parameters received from the SRNC 20 will be 
described in detail with reference to FIGs. 2 and 3, respectively. 

15 [0039] FIG. 2 illustrates a procedure for transmitting service parameters required for allocating a common channel 
from the SRNC to the DRNC according to an embodiment of the present invention. Referring to FIG. 2, in step 201 , 
the SRNC 20 determines service parameters to be transmitted to the DRNC 10 among service parameters included 
in a RAB parameter message received from the CN 30. Here, the SRNC 20 can select partial service parameters 
shown in Table 2 from the service parameters included in the RAB parameter message, as the service parameters to 

20 be transmitted to the DRNC 10. For example, the service parameters to be transmitted to the DRNC 1 0 may include 
the maximum bit rate or the guaranteed bit rate. The service parameters transmitted from the SRNC 20 to the DRNC 
1 0 are service parameters decided to be necessarily considered by the DRNC 1 0 in determining the common channel. 
[0040] In step 202, the SRNC 20 transmits the determined service parameters to the DRNC 1 0 along with an RNSAP 
(Radio Network Subsystem Application Part) signaling message. For example, the RNSAP signaling message used 

25 to transmit the service parameters may be a Common Transport Channel Resources Request message. 

[0041] In step 203, the SRNC 20 receives an RNSAP Response signaling message from the DRNC 10 in response 
to the Common Transport Channel Resources Request message. 

[0042] In step 204, the SRNC 20 detects information on a common channel to be allocated by the DRNC 10 to the 
UE included in the received RNSAP Response signaling message by analyzing the RNSAP Response signaling mes- 
30 sage, and transmits the detected common channel information to the UE using an RRC (Radio Resource Control) 
message. 

[0043] In step 205, upon receiving an RRC Response message from the UE in response to the RRC message, the 
SRNC 20 starts exchanging data from the DRNC 10 with the CN 30, and then ends the procedure after the data 
exchange. 

35 [0044] FIG. 3 illustrates a procedure for transmitting information required for allocating a common channel from the 
DRNC to the SRNC according to an embodiment of the present invention. Referring to FIG. 3, in step 301 , the DRNC 
10 receives an RNSAP signaling message from the SRNC 20. In step 302, the DRNC 10 detects service parameters 
included in the received RNSAP signaling message, i.e., a Common Transport Channel Resources Request message, 
analyzes the detected service parameters, and then determines a common channel to be allocated to the UE based 

40 on the analyzed service parameters. In the case of the uplink, the DRNC 1 0 selects a common channel to be used out 
of the RACH and the CPCH, and then determines the most preferred common channel among PRACHs currently 
available in the DRNC 10 or the CPCH sets for the respective cases, based on the received service parameters. 
Alternatively, the DRNC 10 can determine a common channel to be allocated to the UE considering a state of the 
common channels currently in use. 

45 [0045] In step 303, the DRNC 10 transmits information on the determined common channel to the SRNC 20 along 
with an RNSAP Response signaling message, a response message replying to the RNSAP signaling message received 
from the SRNC 20. The DRNC 10 starts exchanging data from the SRNC 20 with the UE in step 304, and then ends 
the procedure after the data exchange. 

[0046] Next, upon receiving an RAB parameter message from the CN 30, the SRNC 20 selects the type of a common 
so channel to be allocated to the UE based on the service parameters included in the received RAB parameter message, 
and then transmits the service parameters for the selected common channel and the corresponding information to the 
DRNC 10. The DRNC 10 then allocates a common channel to the UE based on the type of the common channel and 
the service parameters, received from the SRNC 20. This procedure will be described in detail with reference to FIGs. 
4 and 5. 

55 [0047] FIG. 4 illustrates a procedure for transmitting the service parameters required for allocating a common channel 
from the SRNC to the DRNC according to another embodiment of the present invention. Referring to FIG. 4, upon 
receiving a RAB parameter message from the CN 30, the SRNC 20 determines service parameters to be transmitted 
to the DRNC 10 among service parameters included in the received RAB parameter message in step 401 . Likewise, 
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the service parameters to be transmitted from the SRNC 20 to the DRNC 1 0 may include some of the service parameters 
included in the RAB parameter message. For example, the service parameters transmitted to the DRNC 1 0 may include 
the maximum bit rate or the guaranteed bit rate. Such service parameters are service parameters decided to be nec- 
essarily considered by the DRNC 1 0 in determining the common channel. 

5 [0048] In step 402, the SRNC 20 selects the type of a common channel to be allocated to the UE based on the 
service parameters included in the received RAB parameter message. Here, if the common channel to be allocated 
to the UE is a downlink common channel, the step 402 can be omitted because only one type of the common channel 
is defined currently. This is because the currently defined downlink common channel includes only the FACH. However, 
the currently defined uplink common channel includes the RACH and the CPCH. Therefore, the SRNC 20 can first 

w select a preferred common channel out of the two common channels, based on the service parameters included in the 
RAB parameter message received from the CN 30, and then send a request for the selected common channel to the 
DRNC 10. Here, the SRNC 20 must previously recognize whether the DRNC 10 supports the CPCH. 
[0049] In step 403, the SRNC 20 transmits the determined service parameters and the common channel information 
to the DRNC 10 along with the RNSAP signaling message. For example, the RNSAP signaling message used in 

is transmitting the service parameters and the common channel information may be a Common Transport Channel Re- 
sources Request message. 

[0050] In step 404, the SRNC 20 receives an RNSAP Response signaling message, a response message answering 
to the RNSAP signaling message, from the DRNC 10. The received RNSAP Response signaling message, i.e., a 
Common Transport Channel Resources Response message, includes information on the common ch annel determined 
20 by the DRNC 10. 

[0051] In step 405, the SRNC 20 detects information on the common channel determined by the DRNC by analyzing 
the RNSAP Response signaling message, and then transmits the detected information to the UE along with an RRC 
message. In step 406, upon receiving an RRC Response message, a response message replying to the transmitted 
RRC message, from the UE, the SRNC 20 starts exchanging data with the CN 30 and the DRNC 10, and then ends 

25 the procedure after the data exchange. 

[0052] FIG. 5 illustrates a procedure for transmitting information required for allocating a common channel from the 
DRNC to the SRNC according to another embodiment of the present invention. Referring to FIG. 5, in step 501 , the 
DRNC 1 0 receives an RNSAP signaling message, i.e., the Common Transport Channel Resources Request message, 
from the SRNC 20. The DRNC 10 detects service parameters and the type of the common channel from the received 

30 Common Transport Channel Resources Request message. 

[0053] In step 502, the DRNC 10 determines whether the type of the common channel included in the Common 
Transport Channel Resources Request message is an RACH, given that the common channel allocated to the UE is 
an uplink common channel. Thus, the DRNC 1 0 determines whether the type of the common channel allocated by the 
SRNC 20 is an RACH. As a result of the determination, if the type of the common channel is the RACH, the DRNC 1 0 

35 proceeds to step 503. Otherwise, if the type of the common channel is not the RACH, but the CPCH, then the DRNC 
10 proceeds to step 506. In addition, if the common channel to be allocated to the UE is a downlink common channel, 
the SRNC 20 is not required to separately determine the type of the common channel as shown in FIGs. 2 and 3, 
because the downlink common channel includes only the FACH. 

[0054] In step 503, the DRNC 10 determines a PRACH based on the detected service parameters. Here, the DRNC 
40 10 determines a PRACH among PRACHs defined in the DRNC 10 based on the service parameters detected from 
the RAB parameter message. Further, the DRNC 1 0 determines a PRACH for the UE considering a state of the PRACHs 
currently in use. 

[0055] Next, in step 504, the DRNC 10 transmits information on the determined PRACH and its associated RACH 
to the SRNC 20 along with an RNSAP Response message, i.e., the Common Transport Channel Resources Response 
45 message. In step 505, the DRNC 1 0 starts exchanging data with the UE and the SRNC 20, and then ends the procedure 
after the data exchange. 

[0056] Meanwhile, if it is determined in step 502 that the type of the common channel is not the RACH, the DRNC 
10 determines a CPCH set based on the detected service parameters in step 506. Here, the DRNC 10 determines a 
preferred CPCH set among CPCH sets defined in the DRNC 10, based on the detected service parameters. Altema- 
so tively, the DRNC 1 0 can also select a CPCH set to be allocated to the UE considering a state of the CPCH sets currently 
in use. Since the CPCH sets have different characteristics, the DRNC 10 can determine a preferred CPCH set con- 
sidering the detected service parameters such as the maximum bit rate. 

[0057] In step 507, the DRNC 1 0 transmits information on the determined CPCH set and the determined CPCH set's 
ID to the SRNC 20 along with an RNSAP Response signaling message, i.e., the Common Transport Channel Resources 
55 Response message. In step 508, the DRNC 10 starts receiving a CPCH from the UE and transmitting the received 
CPCH to the SRNC 20, and then ends the procedure after the data transmission 

[0058] Next, a detailed description will be made of a method for selecting the CPCH among the common channels 
and then allocating the selected CPCH. In general, as for the CPCH, a plurality of CPCH sets are included in the DRNC, 
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and the DRNC allocates different CPCH sets according to the services, in this case, in order to determine a proper 
CPCH set for a specific UE, the DRNC should be provided with information on the service requested or received by 
the UE from the SRNC. Shown in Table 3 is information on the CPCH sets included in the DRNC. 



Table 3 



CPCH Set 


Minimum SF 


Num of PCPCH 


TTI 


Channel Coding 


Num of Signatures 


CPCH Set 1 


SF4 


4 


10ms 


1/3 turbo coding 


8 


CPCH Set 2 


SF8 


8 


10ms 


1/3 turbo coding 


8 


CPCH Set 3 


SF8 


16 


20ms 


1/2 convolution coding 


16 


CPCH Set 4 


; SF16 


32 


20ms 


1/2 convolution coding 


16 



10 



15 



20 



25 



30 



35 



[0059] Referring to Table 3, the DRNC has 4 CPCH sets included in its cell, and the CPCH sets have different 
information on the minimum SF value, the number of physical common packet channels (PCPCHs), the TTI value of 
transport format set information, and the number of signatures available for the CPCPH set. As a result, the UEs 
allocated different CPCH sets are provided with the services having different bit rates. 

[0060] The DRNC uses the maximum bit rate included in the RNSAP signaling message received from the SRNC 
in order to allocate a specific CPCH set to a specific UE among the CPCH sets allocated to the DRNC itself. Upon 
receiving the maximum bit rate, the DRNC selects a CPCH set capable of supporting the received maximum bit rate 
among the CPCH sets currently included in the DRNC, and transmits information on the selected CPCH set to the 
SRNC. 

[0061] Shown in Table 4 are bit rates available for the respective SF values. 

Table 4 



SF 


Channel Bit Rate 


Data Bit Rate (1/2 coding) 


Data Bit Rate (1/3 coding) 


4 


960Kbps 


480Kbps 


320Kbps 


8 


480Kbps 


240Kbps 


160Kbps 


16 


240Kbps 


120Kbps 


80Kbps 


32 


120Kbps 


60Kbps 


40Kbps 


64 


60Kbps 


30Kbps 


20Kbps 


128 


30Kbps 


15Kbps 


10Kbps 


256 


15Kbps 


7.5Kbps 


5Kbps 











40 



45 



[0062] Table 4 shows the bit rates available for the respective SF values according to the coding rates. For example, 
if SF=4, the original channel bit rate is 960Kbps and the bit rate is 480Kbps for 1/2 coding and 320Kbps for 1/3 coding. 
[0063] Next, shown in Table 5 are maximum bit rates and associated CPCH sets available for (or allocable to) the 
corresponding maximum bit rates. 

Table 5 



50 



55 



Max Bit 


Min SFwith 1/2 


Min SF with 1/3 


Available CPCH 


Rate 


coding 


coding 


sets 


5.15Kbps 


256 


128 


CPCH set 1 , 2, 3, 4 


12.2Kbps 


128 


64 


CPCH set 1 , 2, 3, 4 


14.4Kbps 


64 


64 


CPCH set 1 , 2, 3, 4 


28.8Kbps 


64 or 32 


32 


CPCH set 1 , 2, 3, 4 


57.6Kbps 


32 or 16 


32 


CPCH set 1 , 2, 3, 4 


32Kbps 


32 


32 


CPCH set 1,2,3,4 



11 



EP 1 209 939 B1 



Table 5 (continued) 



10 



Ma* Bit 


Min SF with 1/2 

IVIIII w i Willi \ 1 £— 


Min SF with 1/3 

IVIIII Ul Willi 1 / \J 


Available CPCH 


Rate 


coding 


coding 


sets 


64Kbps 


16 


32 


CPCH set 1 , 2, 3, 4 


128Kbps 


8 


8 


CPCH set 1,2, 3 


384Kbps 


4 


4 


CPCH set 1 











[0064] Table 5 shows relationships between the maximum bit rates and associated CPCH sets available for the 
maximum bit rates, based on Tables 3 and 4. For example, the CPCH set 4 is larger than the CPCH set 3, the CPCH 
set 3 is larger than the CPCH set 2, and the CPCH set 2 is larger than the CPCH set 1 in the number of available 

15 CPCHs. Therefore, when the CPCH sets can be simultaneously allocated, it is possible to set an allocation probability 
of the CPCH set 2 to be higher than that of the CPCH set 1 , an allocation probability of the CPCH set 3 to be higher 
than that of the CPCH set 2, and an allocation probability of the CPCH set 4 to be higher than that of the CPCH set 3. 
That is, in FIG. 5, it is preferable to allocate the CPCH set 3 to the UE with the maximum bit rate of 1 28Kbps. In addition, 
it is preferable to allocate the CPCH set 4 to the UE with the maximum bit rate of 64Kbps. 

20 [0065] If the SRNC designates a service parameter for a specific UE among the service parameters included in the 
RAB parameter message received from the CN as the maximum bit rate in an RNSAP signaling message for common 
channel allocation and transmits the RNSAP signaling message to the DRNC, then the DRNC determines a CPCH 
set proper for the maximum bit rate parameter in the RNSAP signaling message among the CPCH sets previously 
included in the DRNC, and then transmits information on the determined CPCH set to the SRNC. Here, a CPCH set 

25 ID can be used for the information on the determined CPCH set. The SRNC transmits the received CPCH set ID to 
the UE using an RRC message. 

[0066] The UE then recognizes information on the CPCH set through system information received over a broadcast 
channel (BCH) from the corresponding cell, and then initiates transmission of the CPCH signal using the received 
CPCH set information. 

30 [0067] Further, the DRNC can transmit the whole information on the CPCH set to the SRNC along with a CPCH set 
ID for the determined CPCH. In this case, the SRNC can receive the whole information on the CPCH set for the UE 
through an RRC message. Therefore, the UE can recognize information on the CPCH set even without receiving the 
BCH information. Specifically, when a UE transitions from a CELL_DCH state to a CELL_FACH state, the UE can 
receive information on the common channel to be used in the CELL_FACH state, directly through RRC message not 

35 through the BCH. That is, when the SRNC has the service parameters for the UE and the UE performs a handover in 
a "connected mode" where the UE is connected to a common radio resource, the UE can receive information on the 
common channel directly through the RRC message and construct the common channel. 

[0068] In addition, when the DRNC transmits only specific information of the information on the CPCH set to the 
SRNC along with the CPCH set ID, the SRNC transmits the information on the CPCH set, received from the DRNC, 

40 to the UE through the RRC message, and the UE constructs a CPCH by preferentially applying the received information 
to overlapped information of the CPCH set information received over the BCH . For example, if the number of signatures 
available for a specific CPCH set is 16, the DRNC can allow the UE to use some of the 1 6 available signatures. The 
DRNC may provide the SRNC with information indicating that only 8 signatures are available for the UE, and upon 
receiving this information from the SRNC, the UE can access the CPCH set using only the allowed signatures. In this 

45 case, the DRNC can control the UE's right to use the CPCH set considering the current state of the cell. 

[0069] The method for transmitting the CPCH set-related information can be equally applied even to the RACH and 
the FACH. The CPCH set can also be equally applied to the PRACH and the FACH, so the present invention is not 
restrictive to the CPCH, but can be applied to all of the common channels. 

[0070] As described above, to select a common channel, the SRNC transmits information stored therein to the DRNC 
50 so that the DRNC may determine a proper common channel for the UE, thus increasing utilization efficiency of the 
common channel and providing various services. In particular, the CPCHs are given different characteristics according 
to CPCH sets , and then, the DRNC sets an effective CPCH set according to service requests from the UE , thus providing 
a high-quality service. 

[0071 ] While the invention has been shown and described with reference to a certain preferred embodiment thereof, 
55 it will be understood by those skilled in the art that various changes in form and details may be made therein without 
departing from the scope of the invention as defined by the appended claims. 
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Claims 

1 . A method for setting a common channel for a packet data service in a mobile communication system including a 
User Equipment, UE, a first Node B providing the packet data service to the UE, a Serving Radio Network Controller, 

5 SRNC (20), connected to the first Node B, a Core Network, CN (30), connected to the SRNC, and a Drift Radio 

Network Controller, DRNC (1 0), connected to the second Node B neighboring the first Node B and also connected 
to the SRNC, the method comprising the steps of: 

transmitting (102; 202, 301 ; 403, 501) parameters to the DRNC; and 

10 

receiving (104; 203, 303; 404, 504, 507) information on a common channel determined based on the param- 
eters from the DRNC; 

characterized in that 

is the common channel for the packet data service is set by the SRNC to the UE through the DRNC and the second 

Node B when the UE is handed over from the first Node B to the second Node B as the UE moves to the second 
Node B; 

the CN has bit rate information for the packet data service and transmits (1 00) the bit rate information to the SRNC, 
the SRNC stores the bit rate information, and the parameters are service parameters including the bit rate infor- 
20 mation for the packet data service; and 

the method further comprises: 

transmitting (204, 304; 405, 505, 508) information on the determined common channel to the UE through the 
DRNC and the second Node B, to allocate the determined common channel to the UE. 

25 

2. The method as claimed in claim 1 , wherein the bit rate information includes a maximum bit rate and a guaranteed 
bit rate. 

3. The method as claimed in claim 1 or 2, wherein the common channel is one of a common packet channel, CPCH, 
30 a random access channel, RACH, and a forward access channel, FACH. 

4. The method as claimed in one of claims 1 to 3, wherein: 

the service parameters are transmitted to the DRNC using a Radio Network Subsystem Application Part, 
35 RNSAP, message; 

the information on the determined common channel is received from the DRNC through an RNSAP response 
message, and 

40 the determined common channel information is transmitted to the UE through a radio resource control mes- 

sage, to allocate the determined common channel to the UE. 

5. The method as claimed in claim 4, wherein the RNSAP message includes a common transport channel resources 
request message. 

45 

6. The method as claimed in claim 4, wherein the RNSAP response message includes a common transport channel 
resources response message. 

7. The method as claimed in one of claims 1 to 6, further comprising the step of: 

50 

determining (101 ; 401) service parameters including the bit rate information for the packet data service, and 
determining (402) a type of a common channel for transmitting packet data according to.the determined service 
parameters, before transmitting the service parameters, 

55 wherein the step of transmitting the service parameters comprises: 

transmitting (403) the determined service parameters and the determined common channel type to the DRNC; 
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wherein the common channel is determined based on the service parameters and the common channel type from 
the DRNC. 

8. The method as claimed in claim 7, further comprising the steps of: 

5 

upon receiving (501) the service parameters and the common channel type from the SRNC, determining (502) 
by the DRNC whether the received common channel type represents a random access channel, RACH; 

determining (503) a physical random access channel, PRACH, based on the service parameters, when the 
10 common channel type represents the random access channel; and 

transmitting (504) information on the determined physical random access channel and the determined random 
access channel as the common channel information to the SRNC. 

15 9. The method as claimed in claim 7, further comprising the steps of: 

determining (506) by the DRNC a common packet channel, CPCH, set according to the service parameters, 
when the common channel type represents a common packet channel; and 

20 transmitting (507) information on the determined CPCH set and an identification, ID, of the determined CPCH 

set as the common channel information to the SRNC. 

10. A mobile communication system comprising: 

25 a User Equipment, UE; 

a first Node B capable of providing a packet data service to the UE; 

a Serving Radio Network Controller, SRNC (20), connected to the first Node B; 

30 

a Core Network, CN (30), connected to the SRNC; 
a second Node B neighboring the first Node B; and 
35 a Drift Radio Network Controller, DRNC (10), connected to the second Node B, 

the system being adapted to perform all the steps of the method of one of claims 1 to 9. 



40 Patentanspruche 

1 . Verfahren zum Festlegen eines gemeinsamen Kanals fur einen Paketdatendienst in einem Mobilkommunikations- 
system, das ein Benutzergerat, einen ersten Knoten B, der den Paketdatendienst fur das Benutzergerat bereitstellt, 
einen Serving RNC (20), der mit dem ersten Knoten B verbunden ist, ein Kernnetz (30), das mit dem Serving RNC 
45 verbunden ist, und einen Drift RNC (10) enthalt, der mit dem zweiten Knoten B verbunden ist, der benachbart zu 

dem ersten Knoten B ist, und des Weiteren mit dem Serving RNC verbunden ist, wobei das Verfahren die folgenden 
Schritte umfasst: 

Senden (102; 202, 301; 403, 501) von Parametern zu dem Drift RNC; und 

50 

Empfangen (104; 203, 303; 404, 504, 507) von Informationen uber einen gemeinsamen Kanal, derauf Basis 
der Parameter von dem Drift RNC bestimmt wird; 

dadurch gekennzeichnet, dass: 

55 

der gemeinsame Kanal fur den Paketdatendienst von dem Serving RNC zu dem Benutzergerat uber den Drift 
RNC und den zweiten Knoten B festgelegt wird, wenn das Benutzergerat von dem ersten Knoten B an den 
zweiten Knoten B ubergeben wird, wenn sich das Benutzergerat zu dem zweiten Knoten B bewegt; 
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das Kemnetz uber Bitrateninformationen fur den Paketdatendienst verfugt und die Bitrateninformationen zu 
dem Serving- R NC sendet, wobei der Serving- RNC die Bitrateninformationen speichert und die Parameter 
Dienstparameter sind, die die Bitrateninformationen fur den Paketdatendienst enthalten; und 

das Verfahren des Weiteren umfasst: 

Senden (204, 304; 405, 505, 508) von Informationen uber den bestimmten gemeinsamen Kanal zu dem 
Benutzergerat uber den Drift RNC und den zweiten Knoten B, urn dem Benutzergerat den bestimmten 
gemeinsamen Kanal zuzuweisen. 

Verfahren nach Anspruch 1 , wobei die Bitrateninformationen eine maximal e Bitrate und eine garantierte Bitrate 
enthalten. 

Verfahren nach Anspruch 1 oder 2, wobei der gemeinsame Kanal ein Common Packet Channel, ein Random 
Access Channel oder ein Forward Access Channel ist. 

Verfahren nach einem der Anspruche 1 bis 3, wobei die Dienstparameter zu dem Drift RNC unter Verwendung 
einer Radio-Network-Subsystem-Anwendungsteil-Mitteilung gesendet werden; 

die Informationen uber den bestimmten gemeinsamen Kanal von dem Drift RNC uber eine Radio-Network-Sub- 
system-Anwendungsteil-Antwortmitteilung empfangen werden, und 

die Informationen uber den bestimmten gemeinsamen Kanal zu dem Endgerat uber eine Radio-Ressource-Con- 
trol-Mitteilung gesendet wird, urn dem Benutzergerat den bestimmten gemeinsamen Kanal zuzuweisen. 

Verfahren nach Anspruch 4, wobei die Radio-Network-Subsystem-Anwendungsteil-Mitteilung eine Ressoursen- 
Anforderungsmitteilung fur einen gemeinsamen Transportkanal enthalt. 

Verfahren nach Anspruch 4, wobei die Radio-Network-Subsystem-Anwendungsteil-Antwortmitteilung eine Ant- 
wortmitteilung uber gemeinsame Transportkanalresourcen enthalt. 

Verfahren nach einem der Anspruche 1 bis 6, das des Weiteren den folgenden Schritt umfasst: 

Bestimmen (1 01 ; 401 ) von Dienstparametern, die die Bitrateninformationen fur den Paketdatendienst enthal- 
ten, und Bestimmen (402) eines Typs eines gemeinsamen Kanals zum Senden von Paketdaten entsprechend 
den bestimmten Dienstparametern vor dem Senden der Dienstparameter, 

wobei der Schritt des Sendens der Dienstparameter umfasst: 

Senden (403) der bestimmten Dienstparameter und des bestimmten Typs des gemeinsamen Kanals zu dem 
Drift RNC; 

wobei der gemeinsame Kanal auf Basis der Dienstparameter und des Typs des gemeinsamen Kanals von dem 
Drift RNC bestimmt wird. 

Verfahren nach Anspruch 7, das des Weiteren die folgenden Schritte umfasst: 

beim Empfangen (501) der Dienstparameter und des Typs des gemeinsamen Kanals von dem Serving RNC 
Bestimmen (502) durch den Drift RNC, ob der empfangene Typ des gemeinsamen Kanals einen Random 
Access Channel darstelit,; 

Bestimmen (503) eines Physical Random Access Channel auf Basis der Dienstparameter, wenn der Typ des 
gemeinsamen Kanals den Random Access Channel darstelit; und 

Senden (504) von Informationen uber den bestimmten Physical Random Access Channel und den bestimmten 
Random Access Channel als die Informationen (iber den gemeinsamen Kanal zu dem Serving RNC. 

Verfahren nach Anspruch 7, das des Weiteren die folgenden Schritte umfasst: 

Bestimmen (506) eines Common Packet Channel, der entsprechend den Dienstparametern festgelegt wird, 
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durch den Drift RNC, wenn derTyp des gemeinsamen Kanals einen Common Packet Channel darstellt; und 
Senden (507) von Informationen Ciber den festgelegten bestimmten Common Packet Channel sowie einer 
Kennung des festgelegten bestimmten Common Packet Channel als die Informationen uber den gemeinsa- 
men Kanal zu dem Serving RNC. 

5 

10. Mobilkommunikationssystem, das umfasst: 
ein Benutzergerat; 

10 einen ersten Knoten B, der in der Lage ist, dem Benutzergerat einen Paketdatendienst bereitzustellen; 

einen Serving RNC (20), dermit dem ersten Knoten B verbunden ist, 
ein kernnetz (30), das mit dem Serving RNC verbunden ist; 

15 

einen zweiten Knoten B, der benachbart zu dem ersten Knoten B ist; und 

einen Drift RNC (10), der mit dem zweiten Knoten B verbunden ist, 

20 wobei das System so eingerichtet ist, dass es alle Schritte des Verfahrens nach einem der Anspriiche 1 bis 9 

durchfuhrt. 



Revendications 

25 

1 . Proced§ pour etablir un canal commun pour un service de donnees en paquets dans un systeme de communication 
mobile incluant un equipement d'utilisateur, UE (User Equipment), un premier Node B (station de base), foumissant 
le service de donnees en paquets a I'UE, un controleur de reseau radio de desserte, SRNC (Serving Radio Network 
Controller) (20), connecte au premier Node B, un reseau coeur, CN (Core Network) (30), connects au SRNC, et 
30 un controleur de r£seau radio de routage, DRNC (Drift Radio Network Controller) (10), connecte au second Node 

B votsin du premier Node B et egalement connecte au SRNC, le procede comprenant les Stapes suivantes : 



on emet (102; 202, 301; 403, 501) des parametres vers le DRNC; et 

on regoit (104; 203, 303; 404, 504, 507) de Pinformation sur un canal commun determine sur la base des 
35 parametres provenant du DRNC; 

caracterise en ce que 

le canal commun pour le service de donnees en paquets est 6tabli par le SRNC vers I'UE par I'intermediaire 
du DRNC et du second Node B lorsque I'UE est transfere du premier Node B au second Node B pendant que I'UE 
40 se d6place vers le second Node B; 

le CN dispose d'une information de debit binaire pour le service de donnees de paquets et §met (100) Pin- 
formation de debit binaire vers le SRNC, le SRNC stocke Pinformation de debit binaire, et les parametres sont des 
parametres de service incluant Pinformation de debit binaire pour le service de donnees en paquets; et 

le procede comprend en outre : 

45 

remission (204, 304; 405, 505, 508) d'information sur le canal commun determine, vers P UE par I'intermediaire 
du DRNC et du second Node B, pour allouer a I'UE le canal commun determine. 

2. ProcedS selon la revendication 1 , dans lequel Pinformation de debit binaire comprend un debit binaire maximal et 
so un det>it binaire garanti. 

3. Proced6 selon la revendication 1 ou 2, dans lequel le canal commun est Pun d'un canal de paquets commun, 
CPCH (Common Packet Channel), d'un canal d'acces aleatoire, RACH (Random Access Channel), et d'un canal 
d'acces d'aller, FACH (Forward Access Channel). 

55 

4. Proc6de selon Tune quelconque des revendications 1 a 3, dans lequel : 

les parametres de service sont emis vers le DRNC en utilisant un message de section d'application de sous- 
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systeme de reseau radio, RNSAP (Radio Network Subsystem Application Part); 

I'information concemant le canal commun determine est recue du DRNC par I'intermediaire d'un message de 
reponse de RNSAP, et 

Tinformation de canal commun determine est emise vers I'UE par i'intermediaire d'un message de commande 
5 de ressource radio, pour allouer a I'UE le canal commun determine. 

5. Procede selon la revendication 4, dans lequel le message de RNSAP comprend un message de demande de 
ressources de canal de transport commun. 

10 6. Procede selon la revendication 4, dans lequel le message de reponse de RNSAP comprend un message de 
reponse de ressources de canal de transport commun. 

7. Proc6de selon Tune quelconque des revendications 1 a 6, comprenant en outre l'6tape suivante : 

is on determine (1 01 ; 401 ) des parametres de service incluant I'information de debit binaire pour le service de 

donnees en paquets, et on determine (402) un type de canal commun pour emettre des donnees en paquets 
conformement aux parametres de service determines, avant d'emettre les parametres de service, 
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dans lequel I'etape Remission des parametres de service comprend : 

remission (403) vers le DRNC des parametres de service determines et du type de canal commun determine^ 

dans lequel le canal commun est determine sur la base des parametres de service et du type de canal 
commun provenant du DRNC. 



8. Procede selon la revendication 7, comprenant en outre les etapes suivantes : 

a la reception (501 ) des parametres de service et du type de canal commun provenant du SRNC, on determine 
(502), par le DRNC, si le type de canal commun recu represente un canal d'acces aleatoire, RACH; 
30 on determine (503) un canal d'acces aleatoire physique, PRACH, sur la base des parametres de service, 

lorsque le type de canal commun represente le canal d'acces aleatoire; et 

on emet (504) vers le SRNC, en tant qu'information de canal commun, de 1'information sur le canal d'acces 
aleatoire physique determine et le canal d'acces aleatoire determine. 

35 9. Proced§ selon la revendication 7, comprenant en outre les etapes suivantes : 

on determine (506) par le DRNC un canal de paquets commun, CPCH, etabli conformement aux parametres 
de service, lorsque le type de canal commun represente un canal de paquets commun; et 
on emet (507) vers le SRNC, en tant qu'information de canal commun, de I'information sur le CPCH determine 
40 etabli, et une identification, ID, du CPCH determine etabli. 

10. Systeme de communication mobile, comprenant : 

un equipement d'utilisateur, UE (User Equipment); 
45 un premier Node B (station de base) capable de foumir un service de donnees en paquets a P UE; 

un controleur de reseau radio de desserte, SRNC (Serving Radio Network Controller) (20), connecte au 
premier Node B; 

un reseau coeur, CN (Core Network) (30), connecte au SRNC; 
un second Node B voisin du premier Node B; et 
50 un controleur de reseau radio de routage, DRNC (Drift Radio Network Controller) (10), connects au 

second Node B, 

le systeme etant adapts pour accomplir toutes les etapes du proced§ de I'une des revendications 1 a 9. 
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Description 
PRIORITY 

5 [0001 ] This application claims priority to an application entitled "Apparatus and Method for Allocating Common Chan- 
- nel in a CDMA Mobile Communication System" filed in the Korean Industrial Property Office on November 23, 2000 
and assigned Serial No. 2000-70099, the contents of which are hereby incorporated by reference. 

BACKGROUND OF THE INVENTION 

10 

1 . Field of the Invention 

[0002] The present invention relates generally to a method for allocating a common channel in a CDMA (Code Di- 
vision Multiple Access) mobile communication system, and in particular, to an apparatus and method for allocating a 
15 common channel in the case that a serving radio network controller (SRNC) is different from a drift radio network 
controller (DRNC). 

2. Description of the Related Art 

20 [0003] With the rapid development of the mobile communication industry, a future mobile communication system will 
provide not only a voice (circuit) service but also advanced services such as a data service and an image service. 
Generally, the future mobile communication system employs a CDMA (Code Division Multiple Access) system. The 
CDMA system is classified into a synchronous system and an asynchronous system. The synchronous system is chiefly 
adopted in United States, while the asynchronous system is mainly adopted in Europe and Japan. However, the stand- 

25 ardization work on the future mobile communication system is being separately carried out for the synchronous system 
and the asynchronous system. The European future mobile communication system is called "UMTS (Universal Mobile 
Telecommunication System)". 

[0004] The standardization provides various specifications for the data service and the images service as well as 
the voice service, required in the future mobile communication system, and particularly, for channel allocation. 

30 [0005] A UMTS W-CDMA (Wideband Code Division Multiple Access) communication system, the European future 
mobile communication system, uses a random access channel (RACH) and a common packet channel (CPCH) as a 
reverse common channel, and uses a forward access channel (FACH) as a forward common channel. 
[0006] Among the reverse common channels of the W-CDMA communication system, the RACH can have charac- 
teristics dependent on a TTI (Transmit Time Interval) and a channel coding mode, and is mapped with a physical 

35 random access channel (PRACH) on a one-to-one basis. Further, the PRACH can have characteristics being depend- 
ent on available signatures and an access sub-channel. Therefore, the RACHs can be distinguished (identified) based 
on the TTI and the channel coding mode, while the PRACHs can be distinguished according to the number of available 
signatures and the access sub-channel. In addition, an available spreading factor (SF) can be also used in distinguish- 
ing the PRACHs. 

40 [0007] As the RACHs and PRACHs have various characteristics, they can be used for different purposes according 
to their service types. In addition, information on the RACH/PRACH is broadcast by a Node B, and upon receiving the 
RACH/PRACH information, a UE can select which RACH/PRACH to use depending on the received FtACH/PRACH 
information. Alternatively, the Node B can select the RACH/PRACH to be used by a specific UE based on a service to 
be used by the UE, and then inform the UE of the selected RACH/PRACH. 

45 [0008] Like the RACH, the FACH and the CPCH also have different characteristics to provide different services, so 
that the UE can select proper FACH and CPCH according to the characteristics of the FACH and CPCH provided from 
the Node B. Alternatively, the Node B can determine the FACH and the CPCH to be used by the UE and then transmit 
information on the determined FACH and CPCH to the UE. 

[0009] Meanwhile, common channels such as the RACH, the FACH and the CPCH are allocated to the UEs by a 
50 serving radio network controller (SRNC). The SRNC connected to a core network (CN) exchanges information on a 
service provided between the UE and the CN. The SRNC determines a channel to be allocated to the UE using the 
service information transmitted from the CN. 

[0010] Shown in Tables t A to 1C are RAB (Radio Access Bearer) parameters of a service information message used 
by the CN to inform the SRNC of the service information. 
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Table 1A 





IE/Group Name 


Presence 


Range 


IE type and reference 


Semantics description 


5 


RAB parameters 










10 
15 


>Traffic Class 


M 




ENUMERATED 
(conversational, streaming, 
interactive, background, ...) 


Desc: This IE indicates the 
type of application for which 
the Radio Access Bearer 
service is optimised 


>RAB Asymmetry Indicator 


M 




ENUMERATED 
(Symmetric bidirectional 
Asymmetric Uni directional 
downlink, Asymmetric Uni 
directional Uplink, 
Asymmetric 
Bidirectional, ...) 


Desc: This IE indicates 
asymmetry or symmetry of 
the RAB and traffic direction 



Table 1B 





>Delivery Order 


M 




ENUMERATED 
(delivery order 
requested, delivery 
order not 


Desc: This IE 
indicates that whether 
the RAB shall provide 
in-sequence SDU 


25 








requested) 


delivery or not 
Usage: 
Delivery order 
requested: in 
sequence delivery 


30 










shall be guaranteed by 
UTRAN on all RAB 
SDUs 

Delivery order not 
requested: in 


35 










sequence delivery is 
not required from 
UTRAN 




>Maximum SDU 


M 




INTEGER (0.. 


Desc: This IE 


40 


size 






32768) 


Indicates the 










maximum allowed 
SDU size 
The unit is: bit. 
Usage: 


45 










Conditional value: set 










to largest RAB 
Subflow Combination 
compound SDU size 
when present among 


50 










the different RAB 










Subflow Combination 
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Table 1B (continued 


) 


>SDU parameters 




1 to 

<maxRABSubflows 

> 


See below 


Desc: This IE 
contains the 
parameters 
characterizing the 
RABSDUs 
Usage 

Given persubflow with 
first occurence 
corresponding to 
subfiow#1 etc* 


>Transfer Delay 


C-iftrafficConv- 
Stream 




INTEGER (0.. 
65535) 


Desc: This IE 
indicates the 
maximum delay for 
95th percentile of the 
distribution of delay for 
all delivered SDUs 
during the lifetime of a 
RAB, where delay for 
an SDU is defined as 
thetimef rom a request 
to transfer an SDU at 
one SAP to its delivery 
at the other SAP 
The unit is: 
millisecond. 
Usage: 



Table 1C 





>Traffic Handling priority 


C-iftrafficlnteractiv 




INTEGER {spare (0), 


Desc: This IE specifies 


35 








highest (1), lowest (14), 


the relative importance 








no priority used (15)} (0? 
5) 


for handling of all SDUs 
belonging to the radio 
access bearer compared 
to the SDUs of other 


40 










bearers 










Usage: 




>Allocat»on/Retention 


O 




See below 


Desc: This IE specifies 




priority 








the relative importance 


45 










compared to other Radio 
access bearers for 
allocation and retention of 
the Radio access bearer. 
Usage: 


50 










If this IE is not received, 
the request is regarded 
as it cannot trigger the 
preemption process and 
it is vulnerable to the 
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Table 1C (continued) 



>Source Statistics 


C-iftrafficConv-Stream 




ENUMERATED (speech, 


Desc.: This IE_specifies 


descriptor 






unknown, ? 


characteristics of the 










source of submitted 










SDUs 










Usage: 



10 [0011] The SRNC selects a dedicated channel (DCH) or a common channel using the RAB parameters shown in 
Tables 1A to 1C. If the common channel is selected, the SRNC can select the RACH or the CPCH in response to a 
service request. In addition, a maximum bit rate and a guaranteed bit rate are used in selecting a minimum SF and a 
channelization code to be used by the common channel. That is, the SF and the channelization code to be used by 
the common channel are determined depending on the maximum bit rate and the guaranteed bit rate. Here, the max- 

15 imum bit rate and the guaranteed bit rate are bit rate information of the packet data. 

[0012] In addition, a traffic handling priority and a transfer delay are selected based on the characteristics of the 
physical channel, i.e., based on the sub-channel and the number of signatures. 

[0013] When the UE, with a channel allocated by the SRNC, performs a handover (or handoff), a DRNC, an RNC 
of a Node B newly accessed by the UE, and the SRNC may be changed. The SRNC and the DRNC are distinguished 

20 from the viewpoint of the UE. If the SRNC is connected to the UE not directly, but through the DRNC, then the SRNC 
cannot personally select a channel and allocate the selected channel to the UE. 
[0014] The reasons that the SRNC cannot personalty allocate a channel to the UE are as follows. 
[0015] First, channels allocated to a cell in the DRNC are determined by the DRNC, because the SRNC does not 
have information on the allocated common channel in the DRNC. For this reason, the SRNC cannot determine a 

25 common channel allocated to the cell in the DRNC. Second, the DRNC or the CN does not have information on a 
service provided to the UE, so it is difficult to allocate a common channel to be used by the UE. Thus, conventionally, 
when the SRNC is connected to the UE through the DRNC, i.e., when the UE performs a handover, the UE cannot be 
allocated a common channel. 

30 SUMMARY OF THE INVENTION 

[001 6] It is, therefore, an object of the present invention to provide a method in which a serving radio network controller 
(SRNC) shares service information provided from a core network, so that a drift radio network controller (DRNC) can 
allocate a common channel to a UE. 

35 [0017] It is another object of the present invention to provide a method in which an SRNC provides a signaling 
message having service information received from a CN to a DRNC, so that the SRNC and the DRNC exchange 
information required in allocating a common channel to a specific UE handed over from the SRNC to the DRNC. 
[001 8] To achieve the above and other objects, there is provided a method for setting a common channel for a packet 
data service by an SRNC through a Node B to a UE and a DRNC when the UE is handed over from a first Node B to 

40 a second Node B as the UE moves to the second Node B, in a mobile communication system. The mobile communi- 
cation system includes the UE, the first Node B providing the packet data service to the UE, the SRNC connected to 
the first Node B, and a CN (Core Network) connected to the SRNC. The CN has bit rate information for the packet 
data service and transmits the bit rate information to the SRNC. The SRNC stores the bit rate information. The DRNC 
is connected to the second Node B neighboring the first Node B and also connected to the SRNC. The SRNC transmits 

45 service parameters including the bit rate information for the packet data service to the DRNC, and receives information 
on a common channel determined based on the service parameters from the DRNC. The SRNC transmits information 
on the determined common channel to the UE through the DRNC and the second Node B, to allocate the determined 
common channel to the UE. 

[0019] Preferably, the bit rate information includes a maximum bit rate and a guaranteed bit rate. 
so [0020] Preferably, the common channel includes a common packet channel (CPCH), a random access channel 
(RACH) or a forward access channel (FACH). 

BRIEF DESCRIPTION OF THE DRAWINGS 

55 [0021] The above and other objects, features and advantages of the present invention will become more apparent 
from the following detailed description when taken in conjunction with the accompanying drawings in which: 

FIG. 1 illustrates a method for allocating a common channel to a UE in the case where an SRNC is different from 
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a DRNC : according to an embodiment of the present invention; 

FIG. 2 illustrates a procedure for transmitting service parameters required for allocating a common channel from 
the SRNC to the DRNC according to an embodiment of the present invention; 

FIG. 3 illustrates a procedure for transmitting information required for allocating a common channel from the DRNC 
5 to the SRNC according to an embodiment of the present invention; 

FIG. 4 illustrates a procedure for transmitting the service parameters required for allocating a common channel 
from the SRNC to the DRNC according to another embodiment of the present invention; and 
FIG. 5 illustrates a procedure for transmitting information required for allocating a common channel from the DRNC 
to the SRNC according to another embodiment of the present invention. 

10 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

[0022] A preferred embodiment of the present invention will be described herein below with reference to the accom- 
panying drawings. In the following description, well-known functions or constructions are not described in detail since 
is they would obscure the invention in unnecessary detail. 

[0023] The present invention provides two different embodiments for allocating a common channel to a UE in the 
case where an SRNC to which the UE belongs is different from a DRNC. 

[0024] In a first embodiment, the SRNC transmits service information received from a CN to the DRNC. Upon re- 
ceiving the service information, the DRNC selects a common channel based on the received service information and 

20 then allocates the selected common channel to the UE. 

[0025] In a second embodiment, the SRNC selects a common channel service information received from the CN 
and transmits information on the selected common channel to the DRNC. Upon receiving the information on the com- 
mon channel, the DRNC allocates a common channel to the UE based on the received common channel information. 
In the first and second embodiments, the common channel selected by the SRNC may be identical to or different from 

25 the common channel selected by the DRNC. 

[0026] A description of the first embodiment will be given herein below. As stated above, the service information 
transmitted from the CN to the SRNC is shown Tables 1 A to 1C. In this embodiment, the SRNC should transmit the 
service information received from the CN to the DRNC. Thus, a definition of a message transmitted from the SRNC to 
the DRNC will be given. 

30 [0027] The SRNC can transmit the service information received from the CN to the DRNC by including it in a Common 
Transport Channel Resources Request message. The SRNC transmits some or all of the service information received 
from the CN to the DRNC, using the Common Transport Channel Resources Request message. Upon receiving the 
Common Transport Channel Resources Request message, the DRNC detects the service information included in the 
received Common Transport Channel Resources Request message. The DRNC then allocates a common transport 

35 channel or a common physical channel to the UE based on the detected service information. Shown in Table 2 is a 
format of the Common Transport Channel Resources Request message according to the first embodiment of the 
present invention. 

40 



45 



50 
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Table 2 



10 



15 



20 



25 



30 



35 



40 



45 



50 



IE/Group Name 


Presence 


Range 


E type and 
reference 


Semantics description 


Criticality 


Assigned 
Criticality 


Message Type 


M 




9.2.1.40 




YES 


Reject 


Transaction ID 


M 




9.2.1.59 




YES 


Reject 


D-RNTI 


M 




9.2.1.25 




YES 


Reject 


C-ID 


O 




9.2.1.61 


Request a new 
transport bearer or to 
use an existing bearer 
for the user plane 


YES 


Reject 


Transport Bearer 

Rpnupct Inrii r*atnr 

IXCVJUCdL UlVUWllAJl 


M 




9.2.1.60 


Indicates the hu 
trancnort hearer to be 

used for the user 

plane 


YES 


Reject 




M 












WAR inffimnivfion 

I\JrVX-J Li Uvl llldUVJll 




0..1 


% 
4 


& 


i 




>Traffic Class 


O 




1 




I 


1 


^>T) AD A nrmmAffu 

-^ivrvu /\syiniiie uy 
Indicator 


0 




& 


i 


1 


1 


ivi dAii i luiu oil rvdic 






i 


u 






>friiar5intftf»rt Hit Pntp 

— VJlulicUIlvvU Ull 


o 
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[0028] Table 2 shows some of the service information received from the CN. Specially, it is noted that in table 2, 
55 parameters mentioned following "the RAB information" row, i.e., from m >Traffic Class'Xo ">Oueuing Allowed", can be 
included in the RAB information and thus, they can be grouped in the RAB information. That is, in selecting service 
information required for selecting a common channel, the SRNC may select all of the service information received from 
the CN or partially selects only the necessary information shown in Table 2. 
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[0029] The service information required by the DRNC in allocating a common channel to the U E includes the following 
parameters that should be transmitted from the SRNC to the DRNC. 

(1) Maximum Bit Rate 

5 

[0030] The maximum bit rate represents a requirement for a maximum value of a bit rate of data to be transmitted/ 
received over the common channel. Therefore, upon receiving the maximum bit rate, the DRNC allocates the common 
channel within a range not exceeding the maximum bit rate. This is because the maximum bit rate can become a 
criterion for determining a spreading factor (SF) indicating a bit rate for a physical channel. Therefore, the maximum 
io bit rate can become a criterion for selecting a random access channel (RACH) rather than a common packet channel 
(CPCH),fortheSF<32. 

(2) Guaranteed Bit Rate 

15 [0031 ] The guaranteed bit rate represents a requirement for a guaranteed value of a bit rate of data to be transmitted/ 
received over the common channel. Therefore, upon receiving the guaranteed bit rate, the DRNC allocates the common 
channel within a range capable of guaranteeing the received guaranteed bit rate. For example, if the received guar- 
anteed bit rate requires a spreading factor SF=16, the DRNC allocates the CPCH rather than the RACH. In addition, 
the DRNC allocates a CPCH set capable of supporting the SF=1 6 among CPCH sets. Likewise, even in the case of a 

20 forward access channel (FACH), the DRNC allocates a secondary common control physical channel (S-CCPCH) ca- 
pable of supporting the spreading factor SF=1 6. 

[0032] In addition to the maximum bit rate and the guaranteed bit rate, the service information required by the DRNC 
in allocating a common channel to the UE includes Traffic Class, RAB Asymmetry Indicator, Delivery Order Transfer 
Delay, Traffic Handling Priority, and Allocation/Retention Priority parameters. These parameters can be used by the 

25 DRNC as criterions for selecting a common channel. 

[0033] FIG. 1 illustrates a method for allocating a common channel to a UE in the case where an SRNC is different 
from a DRNC, according to an embodiment of the present invention. Referring to FIG. 1, upon receiving an RAB 
parameter message with service information from a CN 30 (Step 100), an SRNC 20 determines service parameters 
to be transmitted to a DRNC 10 among the service information (or service parameters) included in the received RAB 

30 parameter message (Step 1 01 ). As mentioned above, however, the SRNC 20 can also select a specific common 
channel among available common channels and transmit the selected common channel. For example, in the case of 
an uplink, the SRNC 20 can previously determine (select) a common channel to be used between the RACH and the 
CPCH, and then transmit information of the determined common channel. In this case, the SRNC 20 must recognize 
whether the DRNC 10 provides the CPCH. 

35 [0034] After determining the service parameters to be transmitted to the DRNC 10 among the service parameters 
received from the CN 30, the SRNC 20 transmits the determined service parameters or information on the type of the 
selected common channel to the DRNC 10 along with a Common Transport Channel Resources Request message 
(Step 1 02). Of course, it is also possible to define a new procedure instead of using the Common Transport Channel 
Resources Request message. 

40 [0035] Upon receiving the Common Transport Channel Resources Request message from the SRNC 20, the DRNC 
10 determines a common channel to be used by the UE by detecting the service parameters included in the received 
Common Transport Channel Resources Request message and analyzing the detected service parameters (Step 1 03). 
The DRNC 10 can also determine the common channel to be allocated to the UE considering a current state of the 
common channels in addition to the service parameters included in the received Common Transport Channel Resourc- 

45 es Request message. That is, the DRNC 1 0 can select a common channel less frequently used by other UEs among 
a plurality of available common channels. 

[0036] After determining the common channel to be allocated to the UE, the DRNC 10 transmits information on the 
determined common channel to the SRNC 20 along with a Common Transport Channel Resources Response message 
(Step 104). The Common Transport Channel Resources Response message may include additional information such 
50 as information on a transport channel and a physical channel of the determined common channel, or its priority. 

[0037] A procedure for transmitting the service parameters from the SRNC 20 to the DRNC 1 0 and a procedure for 
determining a common channel by the DRNC 10 using the service parameters received from the SRNC 20 will be 
described in detail with reference to FIGs. 2 and 3, respectively. 

[0038] FIG. 2 illustrates a procedure for transmitting service parameters required for allocating a common channel 
55 from the SRNC to the DRNC according to an embodiment of the present invention. Referring to FIG. 2, in step 201 , 
the SRNC 20 determines service parameters to be transmitted to the DRNC 10 among service parameters included 
in a RAB parameter message received from the CN 30. Here, the SRNC 20 can select partial service parameters 
shown in Table 2 from the service parameters included in the RAB parameter message, as the service parameters to 
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be transmitted to the DRNC 10. For example, the service parameters to be transmitted to the DRNC 10 may include 
the maximum bit rate or the guaranteed bit rate. The service parameters transmitted from the SRNC 20 to the DRNC 
10 are service parameters decided to be necessarily considered by the DRNC 10 in determining the common channel. 
[0039] In step 202, the SRNC 20 transmits the determined service parameters to the DRNC 1 0 along with an RNSAP 
5 (Radio Network Subsystem Application Part) signaling message. For example, the RNSAP signaling message used 
to transmit the service parameters may be a Common Transport Channel Resources Request message. 
[0040] In step 203, the SRNC 20 receives an RNSAP Response signaling message from the DRNC 10 in response 
to the Common Transport Channel Resources Request message. 

[0041] In step 204, the SRNC 20 detects information on a common channel to be allocated by the DRNC 10 to the 
10 UE included in the received RNSAP Response signaling message by analyzing the RNSAP Response signaling mes- 
sage, and transmits the detected common channel information to the UE using an RRC (Radio Resource Control) 
message. 

[0042] In step 205, upon receiving an RRC Response message from the UE in response to the RRC message, the 
SRNC 20 starts exchanging data from the DRNC 10 with the CN 30, and then ends the procedure after the data 
15 exchange. 

[0043] FIG. 3 illustrates a procedure for transmitting information required for allocating a common channel from the 
DRNC to the SRNC according to an embodiment of the present invention. Referring to FIG. 3, in step 301 , the DRNC 
1 0 receives an RNSAP signaling message from the SRNC 20. In step 302, the DRNC 1 0 detects service parameters 
included in the received RNSAP signaling message, i.e., a Common Transport Channel Resources Request message, 

20 analyzes the detected service parameters, and then determines a common channel to be allocated to the UE based 
on the analyzed service parameters. In the case of the uplink, the DRNC 10 selects a common channel to be used out 
of the RACH and the CPCH, and then determines the most preferred common channel among PRACHs currently 
available in the DRNC 10 or the CPCH sets for the respective cases, based on the received service parameters. 
Alternatively, the DRNC 10 can determine a common channel to be allocated to the UE considering a state of the 

25 common channels currently in use. 

[0044] In step 303, the DRNC 10 transmits information on the determined common channel to the SRNC 20 along 
with an RNSAP Response signaling message, a response message replying to the RNSAP signaling message received 
from the SRNC 20. The DRNC 10 starts exchanging data from the SRNC 20 with the UE in step 304, and then ends 
the procedure after the data exchange. 

30 [0045] Next, upon receiving an RAB parameter message from the CN 30, the SRNC 20 selects the type of a common 
channel to be allocated to the UE based on the service parameters included in the received RAB parameter message, 
and then transmits the service parameters for the selected common channel and the corresponding information to the 
DRNC 10. The DRNC 10 then allocates a common channel to the UE based on the type of the common channel and 
the service parameters, received from the SRNC 20. This procedure will be described in detail with reference to FIGs. 

35 4 and 5. 

[0046] FIG. 4 illustrates a procedure for transmitting the service parameters required for allocating a common channel 
from the SRNC to the DRNC according to another embodiment of the present invention. Referring to FIG. 4, upon 
receiving a RAB parameter message from the CN 30, the SRNC 20 determines service parameters to be transmitted 
to the DRNC 10 among service parameters included in the received RAB parameter message in step 401 . Likewise, 
40 the service parameters to be transmitted from the SRNC 20 to the DRNC 1 0 may include some of the service parameters 
included in the RAB parameter message. For example, the service parameters transmitted to the DRNC 1 0 may include 
the maximum bit rate or the guaranteed bit rate. Such service parameters are service parameters decided to be nec- 
essarily considered by the DRNC 10 in determining the common channel. 

[0047] In step 402, the SRNC 20 selects the type of a common channel to be allocated to the UE based on the 
45 service parameters included in the received RAB parameter message. Here, if the common channel to be allocated 
to the UE is a downlink common channel, the step 402 can be omitted because only one type of the common channel 
is defined currently- This is because the currently defined downlink common channel includes only the FACH. However, 
the currently defined uplink common channel includes the RACH and the CPCH. Therefore, the SRNC 20 can first 
select a preferred common channel out of the two common channels, based on the service parameters included in the 
so RAB parameter message received from the CN 30, and then send a request for the selected common channel to the 
DRNC 10. Here, the SRNC 20 must previously recognize whether the DRNC 10 supports the CPCH. 
[0048] In step 403, the SRNC 20 transmits the determined service parameters and the common channel information 
to the DRNC 10 along with the RNSAP signaling message. For example, the RNSAP signaling message used in 
transmitting the service parameters and the common channel information may be a Common Transport Channel Re- 
55 sources Request message. 

[0049] In step 404, the SRNC 20 receives an RNSAP Response signaling message, a response message answering 
to the RNSAP signaling message, from the DRNC 10. The received RNSAP Response signaling message, i.e., a 
Common Transport Channel Resources Response message, includes information on the common channel determined 
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bytheDRNC 10. 

[0050] In step 405, the SRNC 20 detects information on the common channel determined by the DRNC by analyzing 
the RNSAP Response signaling message, and then transmits the detected information to the UE along with an RRC 
message. In step 406, upon receiving an RRC Response message, a response message replying to the transmitted 
5 RRC message, from the UE, the SRNC 20 starts exchanging data with the CN 30 and the DRNC 10, and then ends 
the procedure after the data exchange. 

[0051] FIG. 5 illustrates a procedure for transmitting information required for allocating a common channel from the 
DRNC to the SRNC according to another embodiment of the present invention. Referring to FIG. 5, in step 501 , the 
DRNC 10 receives an RNSAP signaling message, i.e., the Common Transport Channel Resources Request message, 
io from the SRNC 20. The DRNC 1 0 detects service parameters and the type of the common channel from the received 
Common Transport Channel Resources Request message. 

[0052] In step 502, the DRNC 10 determines whether the type of the common channel included in the Common 
Transport Channel Resources Request message is an RACH, given that the common channel allocated to the UE is 
an uplink common channel. Thus, the DRNC 1 0 determines whether the type of the common channel allocated by the 

15 SRNC 20 is an RACH. As a result of the determination, if the type of the common channel is the RACH, the DRNC 1 0 
proceeds to step 503. Otherwise, if the type of the common channel is not the RACH, but the CPCH, then the DRNC 
10 proceeds to step 506. In addition, if the common channel to be allocated to the UE is a downlink common channel, 
the SRNC 20 is not required to separately determine the type of the common channel as shown in FIGs. 2 and 3, 
because the downlink common channel includes only the FACH. 

20 [0053] In step 503, the DRNC 1 0 determines a PRACH based on the detected service parameters. Here, the DRNC 
10 determines a PRACH among PRACHs defined in the DRNC 10 based on the service parameters detected from 
the RAB parameter message. Further, the DRNC 1 0 determines a PRACH forthe UE considering a state of the PRACHs 
currently in use. 

[0054] Next, in step 504, the DRNC 10 transmits information on the determined PRACH and its associated RACH 
25 to the SRNC 20 along with an RNSAP Response message, i.e., the Common Transport Channel Resources Response 
message. In step 505, the DRNC 1 0 starts exchanging data with the UE and the SRNC 20, and then ends the procedure 
after the data exchange. 

[0055] Meanwhile, if it is determined in step 502 that the type of the common channel is not the RACH, the DRNC 
10 determines a CPCH set based on the detected service parameters in step 506. Here, the DRNC 10 determines a 
30 preferred CPCH set among CPCH sets defined in the DRNC 10, based on the detected service parameters. Alterna- 
tively, the DRNC 1 0 can also select a CPCH set to be allocated to the UE considering a state of the CPCH sets currently 
in use. Since the CPCH sets have different characteristics, the DRNC 10 can determine a preferred CPCH set con- 
sidering the detected service parameters such as the maximum bit rate. 

[0056] In step 507, the DRNC 1 0 transmits information on the determined CPCH set and the determined CPCH set's 
35 ID to the SRNC 20 along with an RNSAP Response signaling message, i.e., the Common Transport Channel Resources 
Response message. In step 508, the DRNC 10 starts receiving a CPCH from the UE and transmitting the received 
CPCH to the SRNC 20, and then ends the procedure after the data transmission. 

[0057] Next, a detailed description will be made of a method for selecting the CPCH among the common channels 
and then allocating the selected CPCH. In general, as for the CPCH, a plurality of CPCH sets are included in the DRNC, 
40 and the DRNC allocates different CPCH sets according to the services. In this case, in order to determine a proper 
CPCH set for a specific UE, the DRNC should be provided with information on the service requested or received by 
the UE from the SRNC. Shown in Table 3 is information on the CPCH sets included in the DRNC. 



Table 3 



so 



CPCH Set 


Minimum SF 


Num of PCPCH 


TTI 


Channel Coding 


Num of Signatures 


CPCH Set 1 


SF4 


4 


10ms 


1/3 turbo coding 


8 


CPCH Set 2 


SF8 


8 


10ms 


1/3 turbo coding 


8 


CPCH Set 3 


SF8 


16 


20ms 


1/2 convolution coding 


16 


CPCH Set 4 


SF16 


32 


20ms 


1/2 convolution coding 


16 



[0058] Referring to Table 3, the DRNC has 4 CPCH sets included in its cell, and the CPCH sets have different 
information on the minimum SF value, the number of physical common packet channels (PCPCHs), the TTI value of 
transport format set information, and the number of signatures available for the CPCPH set. As a result, the UEs 
allocated different CPCH sets are provided with the services having different bit rates. 

[0059] The DRNC uses the maximum bit rate included in the RNSAP signaling message received from the SRNC 
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in order to allocate a specific CPCH set to a specific UE among the CPCH sets allocated to the DRNC itself. Upon 
receiving the maximum bit rate, the DRNC selects a CPCH set capable of supporting the received maximum bit rate 
among the CPCH sets currently included in the DRNC, and transmits information on the selected CPCH set to the 
SRNC. 

5 [0060] Shown in Table 4 are bit rates available for the respective SF values. 



Table 4 



10 



15 



20 



SF 


Channel Bit Rate 


Data Bit Rate (1/2 coding) 


Data Bit Rate (1/3 coding) 


4 


960Kbps 


480Kbps 


320Kbps 


8 


480Kbps 


240Kbps 


160Kbps 


16 


240Kbps 


120Kbps 


80Kbps 


32 


120Kbps 


60Kbps 


40Kbps 


64 


60Kbps 


30Kbps 


20Kbps 


128 


30Kbps 


15Kbps 


10Kbps 


256 


15Kbps 


7.5Kbps 


5Kbps 











[0061] Table 4 shows the bit rates available for the respective SF values according to the coding rates. For example, 
if SF=4, the original channel bit rate is 960Kbps and the bit rate is 480Kbps for 1/2 coding and 320Kbps for 1/3 coding. 
[0062] Next, shown in Table 5 are maximum bit rates and associated CPCH sets available for (or allocable to) the 
25 corresponding maximum bit rates. 



Table 5 



30 



35 



Max Bit 


Min SF with 1/2 


Min SF with 1/3 


Available CPCH 


Rate 


coding 


coding 


sets 


5.15Kbps 


256 


128 


CPCH set 1 , 2, 3, 4 


12.2Kbps 


128 


64 


CPCH set 1 , 2, 3, 4 


14.4Kbps 


64 


64 


CPCH set 1 , 2, 3, 4 


28.8Kbps 


64 or 32 


32 


CPCH set 1 , 2, 3, 4 


57.6Kbps 


32 or 16 


32 


CPCH set 1 , 2, 3, 4 


32Kbps 


32 


32 


CPCH set 1 , 2, 3, 4 


64Kbps 


16 


32 


CPCH set 1 , 2, 3, 4 


128Kbps 


8 


8 


CPCH set 1 , 2, 3 


384Kbps 


4 


4 


CPCH set 1 











[0063] Table 5 shows relationships between the maximum bit rates and associated CPCH sets available for the 
maximum bit rates, based on Tables 3 and 4. For example, the CPCH set 4 is larger than the CPCH set 3, the CPCH 
set 3 is larger than the CPCH set 2, and the CPCH set 2 is larger than the CPCH set 1 in the number of available 
CPCHs. Therefore, when the CPCH sets can be simultaneously allocated, it is possible to set an allocation probability 
of the CPCH set 2 to be higher than that of the CPCH set 1 , an allocation probability of the CPCH set 3 to be higher 
than that of the CPCH set 2, and an allocation probability of the CPCH set 4 to be higher than that of the CPCH set 3. 
That is, in FIG. 5, it is preferable to allocate the CPCH set 3 to the UE with the maximum bit rate of 128Kbps. In addition, 
it is preferable to allocate the CPCH set 4 to the UE with the maximum bit rate of 64Kbps. 

[0064] If the SRNC designates a service parameter for a specific UE among the service parameters included in the 
RAB parameter message received from the CN as the maximum bit rate in an RNSAP signaling message for common 
channel allocation and transmits the RNSAP signaling message to the DRNC, then the DRNC determines a CPCH 
set proper for the maximum bit rate parameter in the RNSAP signaling message among the CPCH sets previously 
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included in the DRNC, and then transmits information on the determined CPCH set to the SRNC. Here, a CPCH set 
ID can be used for the information on the determined CPCH set. The SRNC transmits the received CPCH set ID to 
the UE using an RRC message. 

[0065] The UE then recognizes information on the CPCH set through system information received over a broadcast 
5 channel (BCH) from the corresponding cell, and then initiates transmission of the CPCH signal using the received 
CPCH set information. 

[0066] Further, the DRNC can transmit the whole information on the CPCH set to the SRNC along with a CPCH set 
ID for the determined CPCH. In this case, the SRNC can receive the whole information on the CPCH set for the UE 
through an RRC message. Therefore, the UE can recognize information on the CPCH set even without receiving the 

10 BCH information. Specifically, when a UE transitions from a CELL_DCH state to a CELL_FACH state, the UE can 
receive information on the common channel to be used in the CELL_FACH state, directly through RRC message not 
through the BCH. That is, when the SRNC has the service parameters for the UE and the UE performs a handover in 
a "connected mode" where the UE is connected to a common radio resource, the UE can receive information on the 
common channel directly through the RRC message and construct the common channel. 

15 [0067] In addition, when the DRNC transmits only specific information of the information on the CPCH set to the 
SRNC along with the CPCH set ID, the SRNC transmits the information on the CPCH set, received from the DRNC, 
to the UE through the RRC message, and the UE constructs a CPCH by preferentially applying the received information 
to overlapped information of the CPCH set information received over the BCH. For example, if the number of signatures 
available for a specific CPCH set is 16, the DRNC can allow the UE to use some of the 1 6 available signatures. The 

20 DRNC may provide the SRNC with information indicating that only 8 signatures are available for the UE, and upon 
receiving this information from the SRNC, the UE can access the CPCH set using only the allowed signatures. In this 
case, the DRNC can control the UE's right to use the CPCH set considering the current state of the cell. 
[0068] The method for transmitting the CPCH set-related information can be equally applied even to the RACH and 
the FACH. The CPCH set can also be equally applied to the PRACH and the FACH, so the present invention is not 

25 restrictive to the CPCH, but can be applied to all of the common channels. 

[0069] As described above, to select a common channel, the SRNC transmits information stored therein to the DRNC 
so that the DRNC may determine a proper common channel for the UE, thus increasing utilization efficiency of the 
common channel and providing various services. In particular, the CPCHs are given different characteristics according 
to CPCH sets, and then, the DRNC sets an effective CPCH set according to service requests from the UE, thus providing 

30 a high-quality service. 

[0070] While the invention has been shown and described with reference to a certain preferred embodiment thereof, 
it will be understood by those skilled in the art that various changes in form and details may be made therein without 
departing from the spirit and scope of the invention as defined by the appended claims. 

35 

Claims 

1 . A method for setting a common channel for a packet data service by an SRNC (Serving Radio Network Controller) 
to a UE (User Equipment) through a Node B and a DRNC (Drift Radio Network Controller) when the UE is handed 

40 over from a first Node B to a second Node B as the UE moves to the second Node B, in a mobile communication 

system including the UE, the first Node B providing the packet data service to the UE, the SRNC connected to the 
first Node B, a CN (Core Network) connected to the SRNC, and the DRNC connected the second Node B neigh- 
boring the first Node B and also connected to the SRNC, wherein the CN has bit rate information for the packet 
data service and transmits the bit rate information to the SRNC, and the SRNC stores the bit rate information, the 

45 method comprising the steps of: 

transmitting service parameters including the bit rate information for the packet data service to the DRNC; 
receiving information on a common channel determined based on the service parameters from the DRNC; and 
transmitting information on the determined common channel to the UE through the DRNC and the second 
so Node B, to allocate the determined common channel to the UE. 

2. The method as claimed in claim 1 , wherein the bit rate information includes a maximum bit rate and a guaranteed 
bit rate. 

55 3. The method as claimed in claim 1 , wherein the common channel is one of a common packet channel (CPCH), a 
random access channel (RACH) and a forward access channel (FACH). 

4. A method for setting a common channel for a packet data service by an SRNC (Serving Radio Network Controller) 
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to a UE (User Equipment) through a Node B and a DRNC (Drift Radio Network Controller) when the UE is handed 
over from a first Node B to a second Node B as the UE moves to the second Node B, in a mobile communication 
system including the UE, the first Node B providing the packet data service to the UE, the SRNC connected to the 
first Node B, a CN (Core Network) connected to the SRNC, and the DRNC connected the second Node B neigh- 
5 boring the first Node B and also connected to the SRNC, wherein the CN has bit rate information for the packet 

data service and transmits the bit rate information to the SRNC, and the SRNC stores the bit rate information, the 
method comprising the steps of: 

transmitting service parameters including bit rate information for the packet data service to the DRNC using 
10 an RNSAP (Radio Network Subsystem Application Part) message; 

receiving information on a common channel determined based on the service parameters through an RNSAP 
response message from the DRNC; and 

transmitting the determined common channel information to the UE through a radio resource control message, 
to allocate the determined common channel to the UE. 

15 

5. The method as claimed in daim 4, wherein the RNSAP message includes a common transport channel resources 
request message. 

6. The method as claimed in claim 4, wherein the RNSAP response message includes a common transport channel 
20 resources response message. 

7. The method as claimed in claim 4, wherein the bit rate information includes a maximum bit rate and a guaranteed 
bit rate. 

25 8. The method as claimed in claim 4, wherein the common channel is one of a common packet channel (CPCH), a 
random access channel (RACH), and a forward access channel (FACH). 

9. A method for setting a common channel for a packet data service by an SRNC (Serving Radio Network Controller) 
to a UE (User Equipment) through a Node B and a DRNC (Drift Radio Network Controller) when the UE is handed 

30 over from a first Node B to a second Node B as the UE moves to the second Node B, in a mobile communication 

system including the UE, the first Node B providing the packet data service to the UE, the SRNC connected to the 
first Node B, a CN (Core Network) connected to the SRNC, and the DRNC connected the second Node B neigh- 
boring the first Node B and also connected to the SRNC, wherein the CN has bit rate information for the packet 
data service and transmits the bit rate information to the SRNC, and the SRNC stores the bit rate information, the 

35 method comprising the steps of: 

determining service parameters including the bit rate information for the packet data service, determining a 
type of a common channel for transmitting packet data according to the determined service parameters, and 
then transmitting the determined service parameters and the determined common channel type to the DRNC; 
40 receiving information on the common channel determined based on the service parameters and the common 

channel type from the DRNC; and 

transmitting the received common channel information to the UE through the DRNC and the second Node B, 
to allocate the determined common channel to the UE. 

45 10. The method as claimed in claim 9, wherein the bit rate information includes a maximum bit rate and a guaranteed 
bit rate. 

11. The method as claimed in claim 9, further comprising the steps of: 

so upon receiving the service parameters and the common channel type from the SRNC, determining by the 

DRNC whether the received common channel type represents a random access channel (RACH); 
determining a physical random access channel (PRACH) based on the service parameters, when the common 
channel type represents the random access channel; and 

transmitting information on the determined physical random access channel and the determined random ac- 
55 cess channel as the common channel information to the SRNC. 

12. The method as claimed in claim 9, further comprising the steps of: 
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determining by the DRNC a common packet channel (CPCH) set according to the service parameters, when 
the common channel type represents a common packet channel; and 

transmitting information on the determined CPCH set and an ID (Identification) of the determined CPCH set 
as the common channel information to the SRNC. 
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